System and method to better assure correct use of pre-programmed medical devices

ABSTRACT

Systems and methods are provided for performing a medical procedure with respect to a subject. A data storage location of the system is pre-programmed with a plurality of subject data entries, each having subject-specific information associated with it. A user interface receives an identity input from a subject, which corresponds to the identity of the subject. A controller is associated with the database and the user interface, and is programmed to compare the identity input to the subject data entries. If the identity input corresponds to the subject-specific information of a subject data entry, the controller commands a treatment device to perform a medical procedure with respect to the subject. Otherwise, if the identity input does not correspond to the subject-specific information of any of the subject data entries, the controller generates an error signal which prevents the performance of the medical procedure with respect to the subject.

BACKGROUND

1. Field of the Disclosure

The present subject matter relates to systems and methods forcontrolling the performance of a medical procedure on a subject.

2. Description of Related Art

It is axiomatic that the parameters under which an at least partiallyautomated medical procedure is performed, including without limitationblood donations and apheresis, should correspond or be appropriate tothe characteristics of the donor or patient upon which the procedure isbeing performed. For example, when performing a blood donationprocedure, it may be advantageous for a number of parameters, such asthe sex and weight of the donor or patient, to be taken intoconsideration. If the incorrect operational parameters are used, theprocedure may be less efficient than it would otherwise be and/or incertain circumstances could possibly be harmful to the donor or patient.Accordingly, care should be taken that the operational parameterscorrespond to the unique characteristics of the donor or patient.

Typically, information regarding the donor or patient is present in adatasheet or written prescription and entered into the automated deviceor system via a user interface by the operator of the system (e.g., anurse, doctor, or technician) at the beginning of the procedure. Theoperator confirms the settings of the system and the identity of thesubject and then instructs the system to initiate the medical procedure.By relying on manual data entry, there is of course a risk of operatorerror, resulting in operational parameters which do not correspond tothe unique characteristics of the donor or patient. Thus, systems andmethods which reduce the risk of data entry errors would beadvantageous.

SUMMARY

There are several aspects of the present subject matter which may beembodied separately or together in the devices and systems described andclaimed below. These aspects may be employed alone or in combinationwith other aspects of the subject matter described herein, and thedescription of these aspects together is not intended to preclude theuse of these aspects separately or the claiming of such aspectsseparately or in different combinations as set forth in the claimsappended hereto.

In one aspect, a system is provided for performing a medical procedurewith respect to a subject. The system includes a database, a userinterface, a treatment device, and a controller. The database ispre-programmed with one or more subject data entries, each subject dataentry having subject-specific information associated with it. The userinterface is adapted to receive an identity input from a subject. Thecontroller is associated or in communication with the database, the userinterface, and the treatment device, and is configured to compare theidentity input to the subject-specific information of the subject dataentries. If the identity input corresponds to the subject-specificinformation of a subject data entry, the controller commands thetreatment device to perform a medical procedure with respect to thesubject. If the identity input does not correspond to thesubject-specific information of any of the subject data entries, thecontroller generates an error signal that prevents the performance ofthe medical procedure with respect to the subject.

In another aspect, a method is provided for performing a medicalprocedure with respect to a subject. One or more subject data entriesare stored, with each having subject-specific information associatedwith it. An identity input is received from the subject. The identityinput is compared to the subject-specific information of the subjectdata entries. If the identity input corresponds to the subject-specificinformation of a subject data entry, a medical procedure is performedwith respect to the subject. If the identity input does not correspondto the subject-specific information of any of the subject data entries,an error signal is generated to prevent the performance of the medicalprocedure with respect to the subject.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic view of a medical device according to an aspect ofthe present disclosure; and

FIG. 2 is a flowchart which shows the process undertaken by the medicaldevice of FIG. 1 when receiving identity information from a subject andthen performing a medical procedure with respect to the subject.

DESCRIPTION OF THE ILLUSTRATED EMBODIMENTS

The embodiments disclosed herein are exemplary only, and the subjectmatter described herein may be embodied in various forms. Therefore,specific details disclosed herein are not to be interpreted as limitingthe subject matter as defined in the accompanying claims.

FIG. 1 diagrammatically illustrates a system 10 for performing a medicalprocedure with respect to a subject. The system 10 of FIG. 1 includes adata storage location (such as a database 12), a user interface 14, atreatment device 16, and a controller 18. The system may be configuredand used for carrying out any particular medical procedure. Moreparticularly, the system may be configured for carrying out automated orsemi-automated apheresis or blood collection procedures on a healthydonor or patient.

The data storage location may be variously configured and positionedwithout departing from the scope of the present disclosure. For example,the data storage location may be integrated into the system 10 andassociated with the controller 18, as is the case with the database 12of FIG. 1. In other embodiments, the data storage location may be remotefrom the system 10, for example, being located at or in a central serveror storage facility of the owner of the system 10. If the data storagelocation is remotely located, it may communicate with the system 10 byany of a number of known or novel remote access means such as, but notlimited to, wireless Internet access. In another embodiment, the datastorage location is a removable storage device, such as an encodedidentification card, which may be brought into association with thesystem 10 by a subject or operator. Other configurations of the datastorage location may also be employed without departing from the scopeof the present disclosure.

The data storage location may store a wide variety of data andinformation. In the embodiment of FIG. 1, the data storage location (inthe form of a database 12) stores one or more subject data entries 20,with each subject data entry 20 corresponding to a subject (i.e., adonor or patient) upon which a medical procedure is to be performedusing the system 10. The database 12 is pre-programmed with the subjectdata entry 20 for a particular subject at a time prior to the system 10carrying out a medical procedure on that particular subject. Eachsubject data entry 20 includes subject-specific information 22, such asname, weight, sex, age, birth date, address, unique password,fingerprint, facial or retinal data, and/or answer(s) to securityquestions. The subject-specific information 22 corresponds to theidentity of the subject and is compared to identity input 26 which isentered into the system by the subject, as will be described in greaterdetail below.

In addition to the subject-specific information 22, each subject dataentry 20 may include one or more parameters 24 or such parameter(s) maybe calculated or determined by the controller 18 based on the medicalprocedure and/or a combination of the procedure and subject-specificinformation 22. The nature of the parameter 24 may vary depending on thenature of the medical procedure to be performed. Also, the parameter 24may relate to or be derived based on the sex of the subject, the weightof the subject, the acceptable rate at which fluid may be drawn fromand/or returned to the subject (e.g., a citrate infusion rate), etc.

The user interface 14 includes a display for receiving commands andinformation from an operator or subject and displaying instructions forthe operator or subject to perform. The display may be variouslyprovided, such as in the form of a touch screen or, alternatively, ascreen with an associated device which allows an operator or subject tointeract with the user interface 14 (e.g., a keypad or keyboard). Theuser interface 14 also includes an input device for receiving anidentity input 26 from the subject, which corresponds to the identity ofthe subject. As will be described in greater detail below, there are avariety of ways in which a subject may identify him- or herself, so theinput device may be variously configured. In some embodiments, thedisplay serves as an input device, while in other embodiments, the inputdevice is separate from the display.

The principles of the present disclosure may be employed in a widevariety of devices and in a wide variety of procedures. Accordingly, thetreatment device 16, which actually performs (at least part of) amedical procedure on the subject, may be variously configured. In oneembodiment, the treatment device 16 may be an apheresis system, forexample, a centrifuge system configured to draw blood from a subject,separate it into its constituents, and return at least one of thecomponents to the subject. Exemplary centrifuge systems include thosecurrently marketed as the ALYX® and AMICUS® systems by Fenwal, Inc. ofLake Zurich, Ill., as described in greater detail in U.S. Pat. No.6,325,775 and U.S. Pat. No. 5,868,696, respectively, which are herebyincorporated herein by reference. Other treatment devices may also beemployed without departing from the scope of the present disclosure,including (without limitation) dialysis systems, parenteral nutritionsystems and others.

The controller 18 is associated with or in communication with thedatabase 12, the user interface 14, and the treatment device 16. Thecontroller 18 may be configured or programmed with a plurality offunctions or procedures, and has various functions, including (but notlimited to) receiving data from the various other components of thesystem 10, issuing commands to the various other components of thesystem 10, and monitoring the performance of the various othercomponents of the system 10. In one embodiment, the controller 18 isconfigured to compare the identity input 26 which is provided by thesubject to the subject data entries 20 stored in the database 12. If theidentity input 26 corresponds to the subject-specific information 22stored in one of the subject data entries 20 (i.e., if the system 10“recognizes” the subject), the controller 18 will command the treatmentdevice 16 to perform a medical procedure with respect to the subject.This may include determining or accessing the parameter(s) 24 associatedwith that particular subject data entry 20 (if provided) and sending theparameter(s) 24 to the treatment device 16 for use in performing themedical procedure.

If the identity input 26 does not correspond to the subject-specificinformation 22 stored in any of the subject data entries 20, thecontroller 18 may initiate any of a number of responses. In oneembodiment, the controller 18 generates an error signal that preventsthe performance of the medical procedure with respect to the subject.The error signal may trigger audible and/or visual alarms and alerts,including commanding the user interface 14 to show an error message(e.g. “Unable to confirm individual”) on the display. In anotherembodiment, the controller 18 optionally commands the treatment device16 to perform the procedure on the subject using default operationalparameters instead of parameters uniquely suited to the subject.

FIG. 2 illustrates an exemplary manner of using a system 10 according tothe present disclosure. Prior to a medical procedure being performed onthe subject, a subject data entry 20 is pre-programmed into the database12 for the subject. This may be done remotely or by using the userinterface 14. A medical personnel is prompted to enter a variety ofinformation, including at least the subject-specific information 22which will be used to identify the subject. The medical personnel mayalso be prompted to enter one or more parameters 24 to be used whenperforming the medical procedure with respect to the subject. Dependingon the nature of the identity input 26, the nature of thesubject-specific information 22 and, hence, the manner and form in whichit is entered into the database 12 may vary. For example, theinformation may be retrieved from another database, such as a central orremote database by direct interrogation and download, or in response tosubject or medical personnel input. Further, the nature of theparameter(s) 24 may depend on the nature of the medical procedure to beperformed with respect to the subject. When the subject-specificinformation 22 and optionally parameter(s) 24 (if provided) have beenentered into the system 10, the medical personnel may confirm the dataentered, thereby generating a subject data entry 20 which is stored inthe database 12 and is unique to the subject.

At some later time, the subject is brought into the vicinity orproximity of the system 10 or an operable portion of the system 10. Thesubject may be connected to the treatment device 16 upon being broughtinto the vicinity of the system 10 or may be connected to the treatmentdevice 16 at a later time (e.g., after the system 10 has confirmed theidentity of the subject). While in the vicinity of the system 10, thesubject attempts to identify him- or herself to the system 10 byproviding an identity input 26 via the input device of the userinterface 14. The identity of a subject may be expressed in any of anumber of ways, so the system 10 may include one or more different inputdevices for receiving the identity input 26.

In one embodiment, the identity input 26 may take the form of biometricdata, in which case the input device of the user interface 14 isprovided as a biometric scanner or reader. For example, the input devicemay be provided as a fingerprint reader to receive and analyze thefingerprint of a subject. In another embodiment, the input device isprovided as a retina scanner to view and analyze the retina of asubject. In yet another embodiment, the input device includes facerecognition software to view and analyze the face of a subject. Inanother embodiment, the input device is provided as a heart rate monitorto consider the heart rhythm of a subject. In yet another embodiment,the input device includes a microphone or comparable audio device toreceive and analyze the voice of a subject. In another embodiment, theinput device is configured to receive a blood sample from a subject andanalyze the DNA of the subject. Other biometric identifiers may also (oradditionally) be provided by a subject to express his or her identity.

In another embodiment, the subject is provided with a unique subjectidentification card, badge, or removable storage device which isanalyzed by the input device to attempt to identify the subject to thesystem 10. For example, the input device may comprise a bar code reader,with the subject being provided with a subject identification cardhaving personal information encoded into a bar code which can be read bythe input device. In another example, the subject may have a subjectidentification card encoded with personal information and having abuilt-in radio-frequency identification (“RFID”) circuit. The inputdevice comprises an RFID reader which is capable of reading the personalinformation on the card for subsequent analysis by the controller 18.The card may serve as a data storage location, as described above, beingfurther encoded with one or more of the subject's unique operationalparameters 24, rather than pre-programming the parameter(s) 24 into thedatabase 12 or deriving/calculating them by the controller 18. In thiscase, the identity input 26 and the parameter(s) 24, if any, will beread by the input device and, if the identity input 26 corresponds tothe subject-specific information 22 in one or more of the subject dataentries 20, the controller 18 will send the parameter(s) 24 from thecard to the treatment device 16. Furthermore, the card may be encodedwith a multiple-treatment regimen, with the result of each treatmentbeing tracked by the system 10 over time.

In one or more embodiments, the controller 18 may be programmed torequire certain one or more of the subject-specific information 22 inthe subject data entries 20 to correspond to the identity input 26. Forexample, the system 10 may require a combination of correctsubject-specific information 22 before proceeding with the medicalprocedure. Specifically, the system 10 may require two or moresubject-specific information 22 to be consistent with the identity input26 and/or with each other. As non-limiting examples, the system 10 mayrequire consistency among a name and sex; a name and password; a nameand fingerprint and medical condition; a fingerprint and facialrecognition; or such other combination as may be selected.

In yet another embodiment, the input device of the user interface 14 isprogrammed to recognize and read authentication software running on anelectronic device, such as a mobile phone or laptop computer.

In another embodiment, the user interface 14 is programmed to receive apersonal identification number, code, or password from the subject. Ifthe display of the user interface 14 is a touch screen, the personalidentification number may be directly entered using the display (therebyallowing the display to serve as the input device). Alternatively, aninput device comprising a keypad or keyboard may be provided to allowthe subject to enter the personal identification number.

When the subject has provided the identity input 26 to the system 10,the controller 18 compares the identity input 26 to the subject dataentries 20 stored in the database 12. As described above, if theidentity input 26 corresponds to the subject-specific information 22stored in one or more of the subject data entries 20, as required by thesystem 10 (represented in FIG. 2 as a “YES” response to the “if-then”diamond containing the words “Medical Device confirms individual'sauthentication”), the system 10 has successfully identified the subject.The controller 18 will then command the treatment device 16 to perform amedical procedure with respect to the subject, which may include thecontroller 18 computing, retrieving, or accessing the parameter(s) 24associated with that particular subject data entry 20 and sendingit/them to the treatment device 16 for use in performing the medicalprocedure.

If the controller 18 is unable to match the identity input 26 to thesubject-specific information 22 stored in any of the subject dataentries 20 (represented in FIG. 2 as a “NO” response to the “if-then”diamond containing the words “Medical Device confirms individual'sauthentication”), the system 10 has failed to identify the subject. Inthe embodiment of FIG. 2, the controller 18 responds by disabling ordeclining to proceed with the medical procedure and may generate asignal that prevents the performance of the medical procedure withrespect to the subject. The subject may then be given one or moreadditional opportunities to express his or her identity using the sameor a different identity input 26. As described above, differentresponses to a failed identification may also be initiated withoutdeparting from the scope of the present disclosure.

It will be understood that the embodiments described above areillustrative of some of the applications of the principles of thepresent subject matter. Numerous modifications may be made by thoseskilled in the art without departing from the spirit and scope of theclaimed subject matter, including those combinations of features thatare individually disclosed or claimed herein. For these reasons, thescope hereof is not limited to the above description but is as set forthin the following claims, and it is understood that claims may bedirected to the features hereof, including as combinations of featuresthat are individually disclosed or claimed herein.

1. A system for performing a medical procedure with respect to asubject, comprising: a data storage location pre-programmed with one ormore subject data entries, each subject data entry havingsubject-specific information associated with it; a user interfaceadapted to receive an identity input from a subject; a treatment device;and a controller associated with the user interface and the treatmentdevice and configured to compare the identity input to thesubject-specific information of the one or more subject data entries,and command the treatment device to perform a medical procedure withrespect to the subject if the identity input corresponds to thesubject-specific information of one of the subject data entries or, ifthe identity input does not correspond to the subject-specificinformation of any of the subject data entries, generate an error signalthat prevents the performance of the medical procedure with respect tothe subject.
 2. The system of claim 1, wherein the controller isconfigured to command the treatment device to perform a medicalprocedure based at least in part on the subject-specific informationcorresponding to the identity input if the identity input corresponds tothe subject-specific information of one of the subject data entries. 3.The system of claim 1, wherein the user interface comprises a biometricscanner.
 4. The system of claim 3, wherein the user interface comprisesa fingerprint reader.
 5. The system of claim 3, wherein the userinterface comprises a retina scanner.
 6. The system of claim 3, whereinthe user interface includes face recognition software.
 7. The system ofclaim 3, wherein the user interface comprises a heart rhythm monitor. 8.The system of claim 3, wherein the user interface includes voicerecognition software.
 9. The system of claim 3, wherein the userinterface includes DNA recognition software.
 10. The system of claim 1,wherein the user interface is configured to communicate with a subjectidentification card.
 11. The system of claim 10, wherein the userinterface comprises an RFID reader.
 12. The system of claim 10, whereinthe user interface comprises a barcode reader.
 13. The system of claim1, wherein the user interface is configured to communicate withauthentication software of an electronic device.
 14. The system of claim1, wherein the user interface is configured to receive a personalidentification number from the subject.
 15. The system of claim 1,wherein the data storage location comprises a database integrated intothe system.
 16. The system of claim 1, wherein the data storage locationcomprises a removable storage device.
 17. A method of performing amedical procedure with respect to a subject, comprising: storing one ormore subject data entries, each having subject-specific informationassociated with it; receiving an identity input from a subject;comparing the identity input to the subject-specific information of theone or more subject data entries; and performing a medical procedurewith respect to the subject if the identity input corresponds to thesubject-specific information of one of the subject data entries or, ifthe identity input does not correspond to the subject-specificinformation of any of the subject data entries, generating an errorsignal that prevents the performance of the medical procedure withrespect to the subject.
 18. The method of claim 17, wherein saidperforming a medical procedure with respect to the subject includesperforming a medical procedure based at least in part on thesubject-specific information corresponding to the identity input if theidentity input corresponds to the subject-specific information of one ofthe subject data entries.
 19. The method of claim 17, wherein saidreceiving the identity input from the subject includes receivingbiometric data from the subject.
 20. The method of claim 19, whereinsaid receiving the identity input from the subject includes reading afingerprint of the subject.
 21. The method of claim 19, wherein saidreceiving the identity input from the subject includes scanning a retinaof the subject.
 22. The method of claim 19, wherein said receiving theidentity input from the subject includes analyzing the face of thesubject.
 23. The method of claim 19, wherein said receiving the identityinput from the subject includes monitoring a heart rhythm of thesubject.
 24. The method of claim 19, wherein said receiving the identityinput from the subject includes analyzing the voice of the subject. 25.The method of claim 19, wherein said receiving the identity input fromthe subject includes analyzing the DNA of the subject.
 26. The method ofclaim 17, wherein said receiving the identity input from the subjectincludes communicating with a subject identification card.
 27. Themethod of claim 26, wherein said receiving the identity input from thesubject includes reading an RFID signal.
 28. The method of claim 26,wherein said receiving the identity input from the subject includesreading a barcode.
 29. The method of claim 17, wherein said receivingthe identity input from the subject includes communicating withauthentication software of an electronic device.
 30. The method of claim17, wherein said receiving the identity input from the subject includesreceiving a personal identification number from the subject.